Your Tally import keeps failing. Check ledger names before you blame Tally.

You export a CSV of supplier invoices. Open Tally. Go to Import. Point to the file. Half the rows come in. The other half fail with "Ledger not found." You look at the CSV. The vendor is listed as Acme Steels. You look at Tally. The ledger is Acme Steels Pvt Ltd. That is the whole problem.

Importing into Tally is not complicated. The file is the hard part. Get the file right and the import screen is a formality. Get it wrong and you spend the evening fixing rows one at a time, wondering why Tally will not accept what seems like a perfectly good CSV.

Ledger-name mismatch is a typical import failure. It is fixable. The problem is usually the file, not Tally.

Four things to get right before you open Import

The CSV needs four things to work. Get them right and the import goes smoothly. Get them wrong and you are in for a long evening.

The CSV layout. One invoice per voucher row. Date, voucher type, vendor, item lines, HSN, tax rate, taxable value, tax and total. In the columns Tally expects. Tally is particular about column order. If your CSV has the columns in the wrong order, Tally will either import the wrong data into the wrong fields or refuse the row entirely. Check the Tally import documentation for the exact column sequence before you start.

Vendor ledgers that exist. Every vendor name in the file must match a ledger in Tally. A spelling difference is a failed row. "Acme Steels" does not match "Acme Steels Pvt Ltd." "RK Traders" does not match "R.K. Traders." "Shree Steel" does not match "Shree Steel Works." These are all the same supplier, but Tally treats them as different ledgers. The import fails on every row where the name does not match exactly.

GST ledgers and tax rates. Purchase and CGST/SGST or IGST ledgers must exist and carry the right rates. If your file says 18% GST but the CGST ledger is set to 9%, the import will either fail or post with the wrong tax amount. Check the ledgers before you import, not after.

One consistent date format. DD-MM-YYYY or whatever your Tally company uses. Same format across the whole file. If some rows use DD/MM/YYYY and others use YYYY-MM-DD, the ones with the wrong format will fail. Pick one format and stick to it.

The seven steps

The import process itself is straightforward once the file is ready.

Step 1: Prepare the CSV. One invoice per voucher row. Every field Tally needs, in Tally's column order. If you are exporting from a spreadsheet, make sure the date column is formatted as text, not as a date object. Tally does not always parse date objects correctly.

Step 2: Check the mapping. This is the step everyone skips. Every vendor name in the CSV must match a ledger name in Tally. Every GST ledger must exist with the right rates. Five minutes of mapping before import saves an hour of fixing rows after.

Step 3: Open Import. In Tally Prime, use Gateway of Tally → Import Data (masters or vouchers). Shortcut keys change by version; follow Tally’s import help, not a remembered hotkey. If you are importing new vendors, import masters first, then vouchers.

Step 4: Point to the file. Select the CSV. Tally will show a preview of the columns. Match each column to the Tally field it belongs to. This is a one-time setup per file format. Save the mapping for future imports.

Step 5: Run the import. Tally tells you what came in and what was skipped. The skipped rows are the ones with errors. Fix those rows and re-import only those. Do not re-import the entire file. Tally will duplicate the rows that already came in.

Step 6: Verify in the day book. Open the day book and spot-check a few invoices against the source documents. Check the totals. Check the tax amounts. If something looks wrong, fix it now, not at filing time.

Step 7: Close the batch. Mark it done. File the evidence with the source scans. This is the part that matters at audit time: you can trace every entry back to the source document.

The mapping step everyone skips

In Tally a purchase voucher posts to a vendor's sundry creditor ledger and then to expense or inventory ledgers. GST gets its own ledgers. If the CSV says Acme Steels and Tally has Acme Steels Pvt Ltd, the import fails on that row.

Mapping is deciding, once, which file names go to which Tally ledgers. Do it before you import, not after. A five-minute mapping session saves an hour of fixing rows. The mapping stays the same for every future import from the same supplier. You only need to do it once per vendor.

EntryLedger seeds this mapping from your first batch. Your real vendor list, their GSTINs, and the ledgers they post to. The export comes out already mapped. The import screen becomes a formality because the file is clean before it reaches Tally.

Five errors and their fixes

We have not published a frequency table of Tally import errors. Start with ledger mapping, then dates, tax, HSN, duplicates. EntryLedger flags duplicate invoice number plus seller GSTIN before export when both keys are present.

What changes when the CSV is validated first

The path from photocopy to this file is scan to Tally. If the question is “should we leave Tally for Busy instead of fixing the CSV,” read Busy vs Tally vs a gate. Every one of those import errors can be caught before Tally sees the file. EntryLedger extracts the invoice, proves the GSTIN checksum, proves the HSN, proves the arithmetic, then hands Tally a file that imports cleanly. A wrong total does not sit in your books for a month and surface during reconciliation.

The difference between a CSV and a validated CSV is the difference between "imported with errors" and "imported cleanly." The first one requires a person to trace and fix. The second one requires a person to spot-check and confirm. One is firefighting. The other is process.