Tally Import Errors: LINEERROR Causes and Fixes
You import an XML file of marketplace vouchers into TallyPrime, the progress bar finishes, and the count reads 480 of 512 imported. The other 32 were rejected with LINEERROR entries — and unless you know where to look, they simply vanish from your books. This article explains what LINEERROR means, the causes we see most in e-commerce data, and a fix-and-retry process that does not create duplicates.
What LINEERROR actually means
During import, TallyPrime validates each voucher in the file independently. When one fails validation, Tally skips that voucher, logs a LINEERROR describing the offending element, and keeps importing the rest. That per-voucher behaviour is both a blessing and a trap: one bad ledger name does not sink the whole file, but a partially imported batch quietly understates sales, GST and receivables. After every import, compare the imported count against the source count before you do anything else — the import log (tallyimp or the statistics shown after import, depending on release) tells you how many were accepted.
The six most common causes
| Cause | Typical trigger in marketplace data | Fix |
|---|---|---|
| Ledger does not exist | New fee head, new GST rate ledger, renamed party | Create the ledger, or map to the existing name exactly |
| Stock item does not exist | New SKU listed mid-month | Create the item or map SKU to an existing item |
| Voucher type mismatch | XML says Sales but company uses a renamed or custom type | Match the voucher type name character for character |
| Unbalanced voucher | Rounding, missing fee line | Rebuild the voucher so all amounts net to zero |
| Sign convention wrong | Debits sent as positive amounts | Debits must be negative with ISDEEMEDPOSITIVE set to Yes |
| Date outside period | Voucher dated before books beginning or in a locked period | Correct the date or adjust the company's financial period |
Masters first, vouchers second
The single biggest cause is missing masters. TallyPrime never auto-creates a ledger or stock item during voucher import — anything referenced must already exist in the open company, spelled identically, or the voucher is rejected. The reliable pattern is: import or create masters first, then vouchers. For marketplace sellers that means a one-time setup of party, fee, GST and sales ledgers (our ledger setup guide has a full list) and a living SKU-to-stock-item mapping that gets updated whenever a new listing goes live.
A fix-and-retry process that avoids duplicates
- Note the accepted and rejected counts from the import statistics.
- Open the log and group the LINEERROR lines by cause — usually two or three distinct problems explain all rejections.
- Create the missing masters or correct the XML for those vouchers only.
- Re-import only the corrected vouchers, never the whole file — re-running the full file duplicates the vouchers that already went in.
- Verify the total voucher count now matches the source report.
Step 4 is where spreadsheets fail people. Cutting 32 failed vouchers out of a 512-voucher XML by hand is exactly how second copies of the other 480 sneak in.
Two subtler causes round out the list. Amount precision: TallyPrime works to two decimals, and source data carrying more precision can produce vouchers that are off by a paisa and fail to balance — round at the line level, then force the voucher to net to zero with an explicit rounding line where needed. And character handling: ledger names containing special characters must arrive encoded exactly as Tally stores them, or the text match fails even though the names look identical on screen. Both faults are invisible in a casual file review, which is why eyeballing the XML is a poor substitute for validating it against the company's actual master list before import.
Preventing LINEERROR before it happens
Every cause above is detectable before Tally ever sees the file, and that is the approach TallySutra takes. It validates each batch against your ledger and item mappings while converting Amazon, Flipkart and Meesho reports into vouchers, flags unmapped names for you to resolve, and holds everything for CA approval before export. Its re-imports are duplicate-safe: the Gateway tracks what has been posted and skips it, so a retry after fixing masters only sends what is missing — and it validates the open company before posting anything. The result is imports that go in at 100 percent or not at all, which is the only acceptable standard for books of account. See how the validation works, and if you are setting up the pipeline for the first time, start with the complete XML import guide.
Frequently asked questions
Where do I see the reason a voucher was rejected during import?
TallyPrime shows import statistics after the run and writes rejected entries with LINEERROR details to the import log in the company data folder. Group the errors by message — a handful of causes usually explains every rejection.
Will TallyPrime create missing ledgers automatically during import?
No. Voucher import requires every referenced ledger and stock item to already exist in the open company with an exactly matching name. Import or create masters first, then import vouchers.
Can I just re-import the whole file after fixing the errors?
Not safely. The vouchers that succeeded the first time would be created again as duplicates. Re-import only the corrected vouchers, or use a duplicate-safe tool 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