200 suppliers. 200 ledger strings. Map once. Reuse every batch.

A factory in Pune has 200 active suppliers. Each supplier sends a photocopy. The scan reads the name from the header: "Acme Steel Fittings." Tally has a ledger: "Acme Steels Pvt Ltd." One letter different. The import fails with "ledger not found." The clerk edits the CSV, renames the vendor, re-imports. The row goes through. The next batch has the same problem. And the next.

That is the most common Tally import failure in Indian AP. It is not a product failure. It is a mapping problem. The scan extracts what it sees. Tally expects what it was told. The two strings are not the same. Mapping is the bridge.

Why names do not match

Suppliers abbreviate. "Acme Steel Fittings" on the letterhead. "Acme Steels Pvt Ltd" in Tally. "RK Traders" on the scan. "R.K. Traders" in Tally. "Shree Steel" on one invoice. "Shree Steel Works" on the next. Same supplier, three names. Tally treats each as a different ledger.

OCR makes it worse. "Acme Steels" with an extra S. "Pvt. Ltd." with a dot vs without. "AND" vs "&". These are not product failures. They are the reality of photocopies.

Where mapping happens

Day 1 in a new workspace: 200 invoices from 50 suppliers. The import fails on 40% of the rows because of name mismatches. The clerk fixes them. The fixes become the mapping table. Day 2: 80% import cleanly. Day 5: 90%. By day 30, the mapping covers most of the active supplier base. New vendors get added as they appear. Your console shows straight-through on your own paper. Mapping is how you get there.

The mapping table is not magic. It is a spreadsheet. Scan-name to Tally-ledger. We store it in the workspace. It reuses. If a supplier changes their name on the letterhead, the mapping needs updating. That is an accounts-head job, not a product feature.

What the gate does not do

We do not auto-map vendor names. We do not fuzzy-match "Acme Steels" to "Acme Steel Fittings." We do not create ledgers in Tally. We write the name we extracted. Tally decides whether the ledger exists. If it does not, the import fails. That is the correct failure: the gate proved the GSTIN and the rupees. It does not prove the ledger name.

One GSTIN per ledger. If a supplier has two GSTINs (MH and KA plants), they should have two Tally ledgers. Mapping is GSTIN-to-ledger, not name-to-ledger. A name match without a GSTIN match is how sister-company ITC lands in the wrong place. Link PAN vs master.

Common mistakes

Mapping by name only. "Acme" maps to one ledger. Then two suppliers named "Acme" arrive. Both map to the same ledger. Both post. One is wrong. Map by GSTIN, not by name. And spell it identically in the register, or the diff against 2B becomes guesswork.

Re-importing the whole file. The clerk fixes 40 rows. Re-imports the full 200. The 160 clean rows duplicate. Use day-batch or vendor-batch so you can re-import only the fixed rows. Link Tally import.

Adding a second ledger. "Acme Steels" and "Acme Steel Fittings" both exist as Tally ledgers. The import alternates between them. Two ledgers for one supplier. Two Tally reports. One mapping. One ledger. Seed it in your workspace.

Where the mapping lives

The mapping table is yours. It lives in the workspace. We do not sell it. We do not share it. It reuses. If the first batch covers 150 of 200 suppliers, the remaining 50 get added as invoices arrive. The console shows straight-through, not 100% mapping coverage. New vendors and edge cases are the remainder. Those get added, not forced.