Every month-end has a version of the same scene: a pile of bills, a cup of coffee gone cold, and someone — the owner, or the accountant the owner pays — keying purchase vouchers into Tally one at a time. Date, party, amount, tax split, save. Repeat eighty times. It's the kind of work that feels like progress and is mostly just transcription.
The thing nobody tells you is that the transcription isn't the expensive part. The expensive part is the mistakes that ride along with it — a tax amount keyed wrong, a ledger picked from the wrong head, a GSTIN that doesn't match — which then surface weeks later as a mismatch when you try to claim the credit. So this is really two questions, not one: how do you get the data into Tally without typing it by hand, and how do you make sure the data that lands is clean enough to actually use?
What "getting it into Tally" actually means
People imagine the hard part is an import button they can't find. It isn't. TallyPrime will happily import vouchers from Excel, XML, or JSON — you go to Gateway of Tally → Import Data → Vouchers, point it at a file, and it runs. (If you've heard you must convert everything to XML first, that was true of the older Tally.ERP 9 era; modern TallyPrime imports Excel directly using mapping templates.)
The work is everything before you press import. Each expense has to become a voucher, and a voucher is a structured thing — not a photo, not a line in a spreadsheet you scribbled. You're telling Tally: this is a purchase voucher, dated this, against this party ledger, posting to this expense ledger, with this much CGST/SGST/IGST to these tax ledgers, totalling this. The import is the easy 10%. The mapping — turning a receipt into those fields — is the 90%.
The data Tally needs per voucher
Here's the honest minimum. For a GST purchase voucher to import cleanly, each row needs:
- Voucher type (Purchase) and voucher date
- An invoice / reference number
- The party ledger name — the supplier
- The expense or purchase ledger the spend posts to
- The taxable amount, then the GST split (CGST, SGST, IGST) against the right tax ledgers
- The total invoice value
- The supplier's GSTIN, for anything you intend to claim ITC on
Two of those fields are where imports quietly fail. First, the ledger names have to already exist in Tally and match exactly. "Travel" in your sheet and "Travelling Exp" in Tally are two different things to the import engine — that row fails. Tally imports masters and vouchers in order for a reason: the party, expense, and tax ledgers have to be there before the voucher that references them. Second, the GST split has to be right at the row level, because that's the number your accountant will later reconcile against the portal. A voucher that imports "successfully" with the wrong tax head is worse than one that fails loudly — it looks done and isn't.
When an import runs, Tally hands back a log with success and failure counts. The failures are almost always one of those two things: a ledger name it didn't recognise, or a date or amount in a format it couldn't read. Clean data in is the whole game.
The three ways people actually do this
Let me lay them out fairly, because the right answer depends on your volume.
1. Manual entry. Someone types each voucher into Tally directly. For very low volume — a handful of bills a month — this is genuinely fine, and arguably the least error-prone, because there's no mapping layer to get wrong. It stops being fine somewhere around the point where it eats a full evening every month.
2. Excel templates, then import. You maintain a structured sheet — Tally even ships sample templates — and build a mapping template (saved under the excelmaps folder) that ties your columns to Tally's fields once, then reuse it. This is a real step up for volume. The catch: someone still has to fill the sheet from the receipts, by hand, which is the transcription you were trying to avoid — just moved upstream into Excel.
3. App-generated, Tally-ready exports. The data is captured once, at the point of spend, with the GST fields and ledger tags already attached, and exported in a shape Tally ingests. This is the fastest path if the capture step actually grabs the structured fields — supplier, GSTIN, tax split — rather than just a photo and a total. If it only grabs a photo, you've saved nothing; you're back to option 2 with extra steps.
None of these is magic. The pattern across all three is the same: the effort is in capturing structured data once, cleanly. Whoever does that least painfully wins.
The reconciliation you can't skip
Getting clean vouchers into Tally is half the job. The other half is making sure those purchase entries match what your suppliers actually reported on the GST portal — your GSTR-2B — because that match is what lets you keep the input tax credit you're claiming. A voucher in Tally is your version of events; the 2B is the government's. ITC survives only where the two agree.
This is also why the "import the wrong tax head and move on" mistake is so costly: it doesn't hurt at import time, it hurts at reconciliation, often months later, when the numbers won't tie and nobody remembers which of three hundred vouchers is wrong. I wrote about the full set of conditions and the deadlines in a receipt isn't a tax invoice — the short version is that clean Tally data is what makes that monthly match fast instead of forensic.
A workflow that doesn't involve retyping
Strip it down and the principle is: capture structured once, import once, reconcile monthly.
- Capture at the point of spend, with the fields Tally needs — supplier, GSTIN, taxable amount, GST split, expense category — not just an image.
- Map your ledgers once. Whether that's a saved Excel mapping template or an app that already tags to your chart of accounts, you do this setup a single time, not every month.
- Import in a batch, then read the log. Fix the handful of rows that failed — almost always a ledger-name mismatch — rather than re-checking all of them.
- Reconcile against GSTR-2B the same week. Claim what matches; chase the suppliers whose invoices are missing while there's still time on the clock.
This is, more or less, the reason Starlog exists: capture a receipt once, it pulls the merchant and amount and lets you set the GST fields then, files the image to your own Google Drive per company, and gives you a Tally-ready export your accountant can bring in without retyping. But the workflow stands on its own. The goal isn't a particular tool — it's to never type the same expense twice, and to make the month-end match boring.